WINMX Assorted Textfiles/Ebooks.tar/Text - Tech - Hacking - Hacking Unix - Part 1.txt

Text File | 2003-09-27 | 19KB | 494 lines

                          - HACKING UNIX -
                              PART ONE:

                    Security and Vulnerabilities
                 -----------------------------------

Completed on 10-17-01 (MM-DD-YY)
By: XT - [DuHo] <http://duho.cjb.net>


&    ** This is a multi-part tutorial,
&    ** please check our website for other
&    ** parts:
&    ** http://duho.cjb.net
&
&    Next part, soon to come out (as of 10-17-01):
&        => System Profiling Unices
&
&    AND MORE TO COME!


******

INDEX:

Introduction
0. - Forword
1. - Audience
2. - Conventions
3. - Orientation

4. - Vulnerabilities
     4.1 - Full Disclosure
            3.1.1 Advantages & Disadvantages
     4.2 - Exploit Code
     4.3 - 'Access Levels' and 'Environments' and 'Security'
5. - Where do vulnerabilities occur?
6. - Who finds vulnerabilities
7. - Last words

****************************************************************

0. Forword

Yes, this is another tutorial trying to put 'all-in-one'. As far is I know
there is not a good and recent written tutorial like this. Old texts do
still have a value though, but i think much is obsolete now. Examples of
such tutorials are:

* User's Guide 1.0 - Phantom
* A Novice's Guide to Hacking (1989) - The Mentor [LOD]
* NEWBIES HANDBOOK ; HOW TO BEGIN IN THE WORLD OF H/P - PlowskÑ Phreak
* THE ULTIMATE BEGINNER'S GUIDE TO HACKING AND PHREAKING - REVELATION [LOA--ASH]
* Beginners Guide to VAX/VMS Hacking (1989) - ENTITY [Corrupt Computing Canada]
* THE NEOPHYTE'S GUIDE TO HACKING (1993) - Deicide

I have read all these when i was first interested and they didn't help me
much in really learning the subject. Especially now much in these
tutorials is outdated and irrelevant. But i think it's not bad to read
them afterall, this is oldskool hacking which is always fun-reading. Also
take a look in the phrack archives (www.phrack.org) in the old issues, for
a look in the past.

At first I wanted to release the 'HACKING UNIX' tutorial as a whole. But I
couldn't wait to release it. I decided to break it up in parts and release
it in parts. I will do my best to complete everything a.s.a.p. This part
on 'Vulnerabilities and security' was finished awhile ago though.  And I'm
almost finished with the next part.

1. Audience

You're probably using windows and you're interested in hacking. You
searched for hacking sites on the internet and there you found tools
(wares) which you can use to hack other people. You have tried netbus and
back orifice or other tools, you've collected them and put them on a new
'hacking page'. You found out that you need a strong l33t handle that
reflects your skillz; like "inv1sibl3 predat0r". You have hacked into your
friends' computers and your friends are truly impressed and people phear
you.

Allright it's over now. Did you ever try any of your stupid warez against
your internet service provider's webserver uh? Didn't work exactly did it?
Well, I think that's why you're here right? Well, you're still a zombie
and I hope that I'll break the lameness out of you with this tutorial so
you can work on becoming a true and well respected hacker for the
community. You'll find out that hacking is not about the results it will
give you, it's the act itself that drives the hacker. Eventually only a
few of you will survive.

2. Conventions

I wanted to make this paper accessible for both beginners and more
advanced readers. Therefor, explanations (like technical jargon) are
explained in side-comments.

E.g.:

....the inetd superdaemon....
{
    The Inetd superdaemon is a service that handles network
    connections for network services that use it.
}

This way, the more advanced reader isn't bothered with information that he
already knows, and the beginner is still able to understand what I am
talking about.

3. Orientation

In a nutshell these are the steps the hacker takes:

An attacker first searches a system that he interested in.
Then he explores the system and it's weaknesses, break into the system and
get full control over the system, remove the traces of the hack and use
methods like backdoors to keep access to the system.
{
    Exploring the system means evaluating it's security and see if you
    are capable of breaking in. In this stage you have to make sure
    you are not showing the victim that you are trying to break in!
}
{
    Breaking into the system means finding vulnerabilities in
    the configuration of a system, or see if there is a known
    vulnerability in the software and exploiting them.
}

In the first few parts I will cover all the steps the attacker takes. You
should then understand how attackers attack, and -with some practice- be
able to do it yourself.
In the later parts (the advanced section) I will go deep into hacking
issues, I will talk about low-level network attacks, trust relations,
encryption, authentication and everything.

In this first part I skip the information gathering (profiling) of your
victim, and start off by introducing you with vulnerabilities; the
problems in systems that make attacks possible.

4. Vulnerabilities

Programs have bugs and bugs can often be taken advantage of.
{
    Bugs that can be taken advantage of to bypass security
    restrictions are called vulnerabilities.
}

This chapter introduces you to the community that searches and fixes
vulnerabilities.

If some individual finds a vulnerability in a server application like the
apache webserver (HTTP server) the individual often notifies the vendor
(the apache project in this example) of the problem. The vendor then looks
into the problem and fixes the vulnerability.
The fix is then provided to the users of the apache webserver in the form
of a work-around, a patch or a new release.

People are made aware of the vulnerability in the product they use, and
fix their servers, or they don't.

Because of this, vulnerabilities are often present in certain versions. So
if the attacker finds out which version of a product the victim uses, he
might find out that his victim uses a vulnerable version of the product.

This being said, the chance of being able to attack the target through a
known vulnerability depends on the degree of detail that the founder of
the problem has disclosed in his publication of the problem.
{
    Papers/Articles that discuss a security vulnerability are called
    'advisories'.
}

4.1 Full-disclosure

__When someone releases the details of a security problem in the degree
that another individual is capable of reproducing the
"state of exploitation"*, we call it a "full-disclosure advisory"__
{
    The "state of exploitation" means 'the compromise of whole or
    part of the target's environment* after bypassing the
    security-policy that the target should have enforced.

    Bypassing the intended security restrictions are -ofcourse-
    discussed in the (full-disclosure) advisory.

    *What exactly I mean with 'environment' in this context will be
    explained in chapter 4.3.
}

4.1.1 Advantages and Disadvantages

The full-disclosure method has advantages and disadvantages for security.

Disadvantages of Full-Disclosure:

The disadvantage for security when writing and publishing a full disclosed
advisory is that many people are capable of attacking vulnerable servers.
And as many administrators do not care about vulnerabilities in software
they use, they have a high chance of being hacked by evil people like you
;-}.

Advantages of Full-Disclosure:

The advantage of full-disclosure is that security-concious programmers
will learn what programming methods are insecure. It also presses the
vendors of programs to quickly fix their crap and make sure it doesn't
happen again.

Full-dislosure has another advantage; admins will feel themselves
pressured to keep their software up-to-date as many people in the public
are capable of exploiting the software.

4.2 Exploit code

Full-disclosure reports often include 'exploit-code' which makes it even
easier to reproduce exploitation state, sometimes the 'sploit-code' is
this user-friendly* that a kid could break into a system with it.
{
    *Though, most of the time the (ab)user has to modify the exploit
    program alittle to make it work against his target.
}

Exploit code is simply a program that will automatically reproduce
exploitation state when you point it to a vulnerable server that
runs the vulnerable software.

The exploit-code is supposed to only be used by admins to test if their
systems are vulnerable. Therefor, some of the exploit code only proves
that the vulnerability exists without being usable for attackers. Although
a good attacker knows how to modify the exploit program to fit his needs.

When someone releases an advisory but doesn't include an exploit, it often
doesn't take long before someone writes one and submits it to bug tracking
mailing lists and exploit archive sites.

4.3 'Access Levels' and 'Environments' and 'Security'

When an attacker exploits a network service, this often doesn't mean that
the system is fully compromised yet. Most network service programs do not
require full system access for their tasks and are preferred to have
low-privileges.
{
    Privileges involve access control rights on files, network
    resources, memory access, system calls etc.

    This will be called the program's (or users') 'environment'
    throughout the rest of this guide.
}

Though sometimes a network service requires superuser privileges for
certain tasks. A good process only runs particular tasks with super-user
privilege and not the whole process.

When an attacker compromises whole or part of a target process' the
attacker atleast has a more flexible environment where it becomes easier
to gain superuser privileges.
{
    The scenario where the attacker has compromised an environment
    where he can read files and execute programs is called 'local
    access'. Many admins don't really care about vulnerabilities in
    programs that are not accessible through network services and
    often don't bother to fix these problems because it doesn't seem
    like a direct threat.
}

No system is totally secure, all an admin can do to minimize the danger of
a vulnerable or misconfigured server program, is to minimize the
resources the programs have access to. This minimizes the environment of
an attacker that gained access to that program's environment and makes it
harder for the attacker to gain full access.
{
    A good security setup is created by first disabling everything,
    and then discover what *has* to be enabled.

    After that the admin simply fixes known security problems when
    they come out.
}

So security is all about evaluating what privileges a program or user
needs (and doesn't need).

The 'environment' I'm talking about is enforced by the kernel. The kernel
allows or denies access to files, to network sockets, to I/O devices and
all.

The operating system controls only the program's environment and users's
environment. The programs that provide services to users are responsible
for restricting user access to their own environment
{
    A webserver has a directory like '/var/www/htdocs' where the
    DocumentRoot of the HTTP service resides. The webserver program
    itself is allowed to access the /etc, /usr, /home and /proc
    directory's by the operating system. So the environment that the
    operating system provides to the webserver program is much wider
    than the environment that the webserver provides to site visitors;
    It only gives read access to /var/www/htdocs/, and all
    attempts to access directory's beneith htdocs/ are denied by the
    webserver. Any succesful attempt to break out of the virtual
    environment that is provided by the webserver is a vulnerability.

    Such a vulnerability will give a degree or full access to the webservers
    environment within the system. A full access to the webserver's
    environment means that we can execute programs, browse directory's and
    read all files that the webserver program has access to within
    the system.
}

5. Where do vulnerabilities occur?

Basically vulnerabilities occur in (to list some):

- input handling
- configuration errors
- communication
- trust relationships
- authentication handling
- cryptography bugs
- wrong security policy

So it happens everywhere... it happens at the vendor of a specific
program. It happens at the operating system vendor which puts programs
into a distribution. It happens when admins install things wrong or set
things wrong. It happens when communication protocols are unreliable. It
happens between communication of programs. It happens when users are
stupid. It happens when two programs on a system form security problems.

5. Who finds vulnerabilities

Real hackers find the vulnerabilities.
{
    Hackers search for ways to make a *system do things that shouldn't
    be possible.

    *A system can be anything: a program, a user (person), a
    protocol.
}

A hacker will examine a program on how it works.
{
    This is done for example through tests, reverse engineering or
    simply reading the *source code.

    Source code (for the total beginner) are the programmers'
    instructions in a certain programming language that make up the
    program before it is converted into machine language.
}

He will learn about the procedures a program takes and he will investigate
whether the methods used are secure. The procedures might rely on other
software, kernel calls and network communication.

To make you understand, here's a security advisory to make you see what I
mean;

------------------------------------------------------------------------------
Date: Thu, 20 Sep 2001 21:48:34 +0200
From: "Przemyslaw Frasunek" <[e-mail]>
Subject: Local vulnerability in libutil derived with FreeBSD 4.4-RC
         (and earlier)
Organization: babcia padlina ltd.
To: <[e-mail]>

Hello, OpenSSH derived with FreeBSD 4.4 (and earlier) doesn't drop
privileges before messing with login class capability database. The most
problematic is:
        if (newcommand == NULL && !quiet_login && !options.use_login)
{
                fname = login_getcapstr(lc, "copyright", NULL, NULL);
                if (fname != NULL && (f = fopen(fname, "r")) != NULL) {
                        while (fgets(buf, sizeof(buf), f) != NULL)
                                fputs(buf, stdout);
                                fclose(f);

and
                f = fopen(login_getcapstr(lc, "welcome", "/etc/motd",
                    "/etc/motd"), "r");
[...]
                        while (fgets(buf, sizeof(buf), f))
                                fputs(buf, stdout);
                        fclose(f);

in session.c, which allows to read ANY file in system with superuser
privileges, by defining:

default:\
 :copyright=/etc/master.passwd:

or

 :welcome=/etc/master.passwd: in user's ~/.login_conf. login(1), which is
suid and spawned by telnetd also is vulnerable to similar attack:

    if (!rootlogin)
                auth_checknologin(lc);
[...]
        (void)setegid(pwd->pw_gid);
        (void)seteuid(rootlogin ? 0 : pwd->pw_uid);

Checking for nologin is performed with superuser privileges.
auth_checklogin() is libutil function which displays nologin file, as
defined in login capability database. User can read ANY file in system by
defining:

default:\
 :nologin=/etc/master.passwd:

FreeBSD core team has been aleady informed and official patches were
incorporated into CVS repository *before* 4.4-RELEASE, although 4.4-RC and
earlier verions are vulnerable and needs to be patched with:

http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/lib/libutil/login_cap.c?rev=1.17.2.3&content-type=text/plain

Official advisory is pending. It's possible, that other *BSD systems,
supporting login capability database are also vulnerable.

--
* Fido: 2:480/124 ** WWW: http://www.frasunek.com/ ** NIC-HDL: PMF9-RIPE
*
* Inet: [e-mail] ** PGP: D48684904685DF43EA93AFA13BE170BF
*
------------------------------------------------------------------------------

This is a nice full-disclosure advisory example: It explains the
programming error, the way it can be exploited and it links to the
vendor's patch.

I don't expect you to understand this advisory, but you should have
figured out how it can be exploited (on unpatched systems).

What it says is that a user can create a file called '.login_conf' (which
is probably already there) in their home directory, and when putting a
line like:

----
default:\
:copyright=/etc/master.passwd:
----

or

----
default:\
:welcome=/etc/master.passwd:
----

in the .login_conf file, the login process will then read that file once
you re-login. And because it still has root privileges (it doesn't return
to it's normal user-id) you can place any file name in the .login_conf,
and it will be displayed when you log in! This means you can read the
master.passwd file where the password-hashes for all users are stored.
Ofcourse that file should not readable for a normal user. But if you are
able to read it, like in this case, you can perform a brute-force attack
using password-crackers like CRACK-5.0, and then it will only be a matter
of time before you the root password is recovered.
{
    Though when the root users' password consists of more than 8
    characters and he uses a combination of numeric and alphanumeric
    and other characters as a password, it might take the fastest
    computer on earth over a year to crack it.
}

Now back to the subject...
Note that the hacker had first informed the vendor FreeBSD which created a
patch. After the patch was released, the hacker posted the vulnerability
information as full-disclosure advisory to the BugTraq mailing list and
included a link to the patch (the fix) for the bug which FreeBSD released.

There are also people that don't report bugs to vendors and the public and
use their information for their own sake.

There are alot people in the underground (black-hat hackers)  that keep
the information to themselves. Exploits which are not publicated are
called zero-day's (0-day).

There is nothing you can do about that, you can only minimize the risk by
disabling services that you don't need. And you can restrict service
programs that you do need as explained in chapter 4.3.

7. Last words

I hope that you understand the basic picture of security and
vulnerabilities.

Keep your eyes open for the following parts:
VISIT http://duho.cjb.net/

You are encouraged to spread this file but don't modify it.

XT ([e-mail]): [DuHo] 2001

-EOF-
Size: 20480 bytes
chars: 18821
Words: 2902
Lines: 459